-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serve non-html at documentation domain though El Proxito #6419
Conversation
Download URLs from the footer call will be like, - project-slug.readthedocs.io/_/downloads/pdf/project-slug/latest/ - docs.example.org/_/downloads/pdf/subproject-slug/latest/ Once the user hit these URLs the PDF/ePub/HTML will be serve directly at that URL by El Proxito --no redirect is performed. This commit also includes a change in the El Proxito logic to serve any file as well. Instead of generating the `path` to the filename manually, the django-storage backend is used. This allow us to generate the same URL for non-html files from the `FooterHTML` view than from `ServeDocsBase`.
This allows us to have more control on the storage class (return always True on `.exists()`) and only mock the class when we need a different behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good start, but again we need to not break backwards compat with these changes.
We need to keep this URL to support old links.
Also, re add the new download URL to the main site since it's required to generate the URL for the APIv3
I'm wondering if it would be easier to just support both the dashboard & in-doc download URL's for a time. It seems like we're adding a lot of complexity here, when we really just want to be able to support both for a while. Once we have both working, we can figure out how to migrate the API and other paths we link to. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if it would be easier to just support both the dashboard & in-doc download URL's for a time.
I'm in favor of this because I suspect some people are linking to the old URL.
@davidfischer @ericholscher I'm not sure to follow you. What are the changes I need to do in this PR to be accepted? You both mentioned supporting both, old and new links. This PR won't change that after reverting the commit that removed the URL defined. On the other hand, if you are talking about the NGINX config (#6419 (comment)), I'm not sure it worth to have this in development since the only way to get there is manually writing the URL. We won't change this in the -ops repo. |
I think we were both saying that the old URL (eg. https://readthedocs.org/projects/project-slug/downloads/pdf/latest/) should still work. Since we put that back and just removed the |
Yea, as long as we don't break the old URL's I'm happy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going in a good direction, but I still think the URLConf hack is the wrong approach. Let's either keep serving from the dashboard URL's for now, or just explicitly build the URL, instead of the current hack of adding a URLConf to the main site that we never want to serve.
No need to strip and re-add a portion of the URL when proxying.
This reverts commit 7bc611d.
This reverts commit d4b1275.
There is no need for `full_path` attribute. It was not used anywhere and the path without the domain does not make sense and will be broken.
This feels close, but I still don't like that we're serving the URL's on all proxito domains. Locally this works: Downloads the This all leads back to the weirdness around URL's and domains, but this is definitely not ready to ship as it is currently implemented. We need to have a better way of download this project's PDF, not just ship our old general "download any PDF endpoint" onto the doc domains. |
The code looks good and I think we agree we want this. Although, I'm blocking it because I suppose we want to have a discussion/talk about how the URLs will look like. We've talked already about this but we didn't make a decision yet. |
This PR is ready for re-review. We decided to use these URLs to serve files for download:
The latest commits implement this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a good change, I think we're pretty much ready once the tests pass and we add a couple docstrings. 👍
I'm merging this PR now. Downloads are ready to start being served by El Proxito. I've already opened the -ops PRs needed together with this change for the deploy. |
Download URLs from the footer call will be like,
Once the user hit these URLs the PDF/ePub/HTML will be serve directly at that URL by El Proxito --no redirect is performed.
This PR also includes a change in the El Proxito logic to serve any file as well. Instead of generating the
path
to the filename manually, the django-storage backend is used. This allow us to generate the same URL for non-html files from theFooterHTML
view than fromServeDocsBase
.Also, the "Downloads" link that point to the Dashboard in the footer is removed.Closes #5855
Closes #6100